This invention relates generally to improvements in computer processors that execute relatively simple instructions in hardware controlled execution units and execute relatively complex instructions in a milli-mode architected state with vertical microcode (i.e., millicode) routines executing in the same hardware controlled execution units, and more particularly to millicode store access checking instructions with reduced delays.
Instruction sets used in computer systems employing so-called Complex Instruction Set Computing (CISC) architecture include both simple instructions (e.g., Load, or Add) and complex instructions (e.g., Program Call, or Load Address Space Parameters). As the computer systems have become more powerful, larger percentages of the instruction set have been implemented using hardware execution units to increase the systems performance. Conventionally, complex functions are implemented in microcode because building hardware execution units to execute them is expensive and error prone.
Implementing complex functions in microcode provides flexibility to fix problems and expandability in that additional functions can be included later. In certain prior art machines, where much of the processor is hardware controlled, a dedicated microprocessor based execution unit is often provided in order to implement the complex functions. This unit can be microprogrammed to execute complex instructions and complex functions such as handling interrupt conditions.
A milli-mode operation enables implementation of complex functions in a large, hardware controlled, pipelined, general-purpose digital computer without an additional dedicated microprocessor-based execution unit. Milli-mode implements these complex functions with flexibility provided by firmware and avoids a packaging problem introduced by the inclusion of the additional microprocessor hardware. Rather than an additional microprocessor, milli-mode uses preexisting dataflow and hardware controlled execution units of a pipelined processor to accomplish complex functions. Additional hardware controlled instructions (private milli-mode only instructions) are added to provide control functions or to improve performance. These private milli-mode instructions augment the architected instruction set. Milli-mode routines can intermingle the milli-mode only instructions with architected instructions to implement complex functions.
Milli-mode detection logic in instruction decode logic detects a need to enter milli-mode, and this causes millicode routines to be fetched. The millicode routines are decoded by the decoder hardware and dispatched for execution in the same way as the architected macro-instructions (system-mode instructions).
A majority of the architected macro-instructions that are implemented as hardware controlled instructions can be executed in milli-mode. The set of instructions available in milli-mode can be considered to be an alternate architecture that the processor can execute.
The hardware-executed instructions which are valid only for millicode are generally of a format and a function similar to those of the architected instructions. In this way, the unique hardware required to implement these instructions is minimized, and the simplicity of the hardware design is maintained. This simplicity of hardware controls is a chief advantage of millicode over other forms of internal code (e.g., microcode), which require considerably more unique hardware.
A disadvantage of a millicoded design is that some complex operations require more internal code instructions and/or more machine cycles than with some forms of microcode. In some cases, this is due to the inefficiency of the base instruction set when used to perform these complex operations. Depending on the frequency with which these operations are performed, the impact on overall system performance may be significant.
Millicode that accesses storage, just like architected instructions, are executed by generic hardware constructs. Therefore, millicode is subject to various kinds of hardwired architectural access exception checks and default cache operation behavior. It is desirable for millicode to be capable of accessing a storage location, as well as to avoid or alter certain default operand cache behavior. Any storage access may require proper authority. Prior approaches provide an operand access control register (OACR) mechanism to override many aspects of default operand cache access characteristics. One such approach includes suppressing interrupts when an access exception is detected. However, this is subject to pipeline delays when the OACR needs to be written (after execution) before the affected instruction can issue its operand fetch (occurring much earlier in the processor pipeline). This results in a “bubble” in the pipeline that translates to a reduction in instructions per cycle as delays are incurred to rectify interlock condition between the instruction and the OACR. One example is described in U.S. Pat. No. 5,790,844, which provides a “load and access test” that can check for “load” type exceptions without taking an actual interrupt, but requires a test “tag” from the OACR to be updated to check for a “store” type access exception.
It would be beneficial to develop milli-mode assist instructions enabling millicode access to a storage operand and directly checking for store-type access exceptions without incurring OACR update interlock delays. Accordingly, there is a need in the art for millicode store access checking instructions.